Tech Arsenal 1/Tech Arsenal (Arsenal Computer).ISO/tek-20/nosquick.zip/NETDOC

Text File | 1990-10-20 | 42KB | 912 lines

Notes for TCP/IP "quick start" of the TCP/IP on an MS-DOS computer.

This is a collection of doc files that I accumulated.  I put them
together and deleted some of the repetition.  Refer to the regular
userman doc for detailed answers.  This is only supplemtary to that
documentation.  Information is rather scattered, but I wanted to do a
minimum of editing on the original material, which is quite good.  This
file starts with a quick start, using unique features of this version.
Later, the "Plug and Play" quick start shows another method, and better
tells you what is going on.  Even later, there are some vital things
about using Net/ROM, the Finger, and even (Yikes!) advice on how to run
from floppies.

In case you didn't already know, there are two executable programs, net
and bm.  Net is the networking program (TCP/IP).  Bm is the mailer,
Bdale's Mailer, which is used to read and write messages.  This version
of net and bm use definable path names to files.  Net has a more "user
friendly" TCP/IP interface for non-IP users (mailbox function that gives
as well as receives).  Net is relatively small, very well behaved (never
crashes, and never interferes with other programs running concurrently.)
There are two net versions, one that has the DRSI Packet Adapter driver
installed, and one that doesn't.  For a quick start, you can do the
following:

There are two ways you can set up your directory structure, my way, or
the way everybody else does it.  If you do it my way, the files will be
collected together a little more neatly, and wherever you want them to
be.  If you do it the second way, this version of net will work just like
all the other standard versions.  The second way presumes that files are
found where defined when net and bm were compiled.  The second method is
described later (and in most advice you see on setting up net.)

To do it my way, you will need to use environmental variables to tell net
and bm where to find the required files.  Environmental variables are
strings tucked away in the operating system that let you pass information
to running programs.  The environmental variables for this purpose are,
NETHOME, SPOOL, and PUBLIC.  (I also use TZ to establish time zone
information on mail messages.)  You put lines in your autoexec.bat file,
like those that follow, and reboot the computer, or make a batch file that
sets these variables and then executes net.  (If you get a message like,
"Out of environment space", then I presume you are already savvy of the
environment and know what to do about it.)  In the following example, I
assume you would make directories, NET, SPOOL, and PUBLIC, right off of
root, like the diagram that follows.  (The forward slashes are correct, I
don't think MS-DOS cares but Unix does, and I run this thing on both.
These variable names must be in caps, but the rest of the "set" command
doesn't need to be.)

First, here is how you set the environmental variables:

set NETHOME=/net
set SPOOL=/spool
set PUBLIC=/public
set TZ=CST6CDT

then, the directories and subdirectories (in caps) and files that go into
them, should be set up to look like:

        \NET__ . . . . . . . . . autoexec.net, ftpusers, hosts.net
           |                     bm.rc, net.exe, bm.exe
           |                     alias (optional)
           |                     helpbox.net (optional)
           |
           |\FINGER_. . . . . . .optional finger files

        \SPOOL_. . . . . . . . . * net.log (or put in \net, or
                     |           in \net\mail, or anywhere you want)
                     |
                     |___MAIL. . * user.seq
                     |           * user.txt
                     |
                     |___MQUEUE. * sequence.seq
                     |           * #.txt
                     |           * #.wrk
                     |
                     |___RQUEUE. only used if you're a mail
                                 gateway...

        \PUBLIC_. . . . . . . .  downloadable mbox files

The files marked "*" are created by net or bm when they run.  You can
leave out the optional files until you figure out what they are for.  I
also recommend not messing with Net/ROM until you know how to do it
properly, and have decided to keep your computer on all the time.  You
can mess up the Net/ROM network with this program if it is misused.

If you want to use the alternate method, (files scattered all over the
place), jump subroutine to "Plug and Play", later on.

If you want to be consistent with time stamping of messages, set the
environmental variable TZ = CST6CDT or EST5EDT, or whatever, and it will
timestamp the messages with the proper time if your DOS clock is set to
local time.  (The number in the TZ string is the offset from UTC.)  The
copy of BM that I supply handles this timezone thing correctly.  If you
don't do this, it will use UTC for time stamping and you will need to
set your computer clock accordingly.  The following relates to the
little differences between my code and the mainstream net code:

Examine the sample files I included, edit them to fit your situation, and
you will be ready to go.  You just start net and see if it upchucks some
error messages.  At the command prompt, type "host".  If it doesn't
respond with your host name, re-read the above.  If you are more
cautious, read on before launching the thing.  The "Plug and Play"
information a little further down explains in much more detail how to set
up files for your operation.

      Notes on K5JB version 890421.0i of net.exe - Oct 20, 1990

(This is a synopsis, in reverse version order, from my version notes.)

This note covers general differences between this code and the
mainstream net (non-NOS) code.  Only difference between this version (i)
and the May 28, 1990 version (g/h) is corrected trace to file in
udpdump.c.  Notes that refer to suffix g or h are unchanged.  I re-
organized the files into Lharc files to get a little more needed room.

This version of net is only slightly different from the version
distributed at Dayton in 1989, v 890421.0.  Initially I cleaned up some
MS-DOS end of line sequences in text files written by net.  I also fixed
some problems where tracing sometimes went to screen and sometimes went
to a trace file (if it was enabled).  The included version of bm has its
end of line handling fixed also.

Then, some mailbox (mbox) features were added to permit AX25 users to read
their mail with the "r" command, see who has mail with the "m" command,
list the public directory with the "l" command, download a file from the
public directory with the "g" <filename> command, get help with the "h"
command, and see what version is running with the "v" command.  See
ax_mbx.c for these changes.  (If there is a disconnect during a file
download over a non-Net/ROM AX.25 link, you will get a "Warning" message
about freeing garbage.  Don't worry about it.)  If an operator sends any
characters to the mbox during a download, it will abort as soon as the
queue is empty.

To recover some space for mbox, I combed through the code and #ifdefed
as DEAD that code that did nothing.  I checked all the compiler warnings
to see if they were significant.  I made no changes to modules solely to
correct these warnings because I wanted it to be simpler to compare this
code to work others are doing.  File dates indicate which modules were
changed and which ones weren't.  Since I run the code also in Unix,
portability is important so declarations, etc., aren't compiler
dependent.  Most changes are marked with my call so they are easy to
find with grep K5JB <fn>.

I added file name initialization to permit looking for files in
custom areas.  Three environmental variables are sought by the program:

NETHOME is the directory where net will look for autoexec.net, ftpusers,
hosts.net, helpbox.net, and alias.  (syntax example, set NETHOME=/net)
If it is not specified, net uses root (\).  Logging is normally done in
$NETHOME, if specified.  Session recording also defaults to $NETHOME.

MAILSPOOL is the directory where mail files are found and defaults to
/spool unless you specify differently.  (Syntax, set SPOOL=/spool)  It
will find /spool/mail, /spool/mailq, and other necessary directories
below the /spool directory level.

PUBLIC is the directory where you keep files that are safe to download
over an ax.25 link.  If it is not specified it uses /public.  (Syntax,
set PUBLIC=/public)  By "safe to download over an ax.25 link", I mean
not monsterous, not binary executables.

The environmental variable, TZ, is also recognized, by net and bm, for
date and timestamping messages.  Syntax is, set TZ=CST6CDT.  Note that
the "/" is OK in these path names on MS-DOS.  (TZ may not recognize
daylight savings time in MS-DOS, I don't remember.  If it doesn't, with
DST just change the TZ variable to CDT6CDT, or similar.)

I suggest keeping the helpbox.net file short and point to a longer file
in /public to prevent careless operators from causing a monster dump
with a stroke of one key.  As a sample, I included my copy of
helpbox.net as an mbox discussion below so you can get the idea.

Bm has been modified to work likewise and looks for bm.rc and alias in
$NETHOME if it has been specified.  Otherwise it looks in root.  I also
fixed an array over-run if an operator with broken return key enters a
line of over 128 characters.  (Replaced gets() with fgets().)  (I think
this version of bm.exe is 3.3.1g.)

In summary, if you net have version suffix "f", or later, (optionally)
put the following lines in your autoexec.bat file in root:

set TZ=CST6CDT
set NETHOME=/net
set SPOOL=/spool
set PUBLIC=/public

(You can choose any path names you want.  These happen to be the
defaults if you don't have the environmental variables.  Without them,
net works exactly as in the mainstream release, looking for support
files in root.)

If you are using Desqview, 173k is suitable memory to set aside for the
net program (183k if using the DRSI PC*PA card).  Mem stat shows 13k, or
more available on start, (about 19k available with the PC*PA - its driver
makes net 7328 bytes bigger and needs additional buffer space).  I have
not had any problems with net running in less than that.

This version of net has NEVER crashed.  It sometimes runs continuously
for three or six months between times I shut the computer down to tinker
with it.  I run it on a 10 MHz AT class machine, along with a full blown
bulletin board, and other applications.  To say the least, it is
"mature", heh!

Enjoy!  K5JB

*** EOF

              From the TCP/IP Plug and Play disks (edited):

             Welcome to the KA9Q Internet Software Package.
                       Revision 890421.0i (K5JB)

(Notes collected from various sources and put into one quick-start file.
Most of this information was supplied by Bdale, N3EUA.  There are four
appendices for Net/ROM, Finger, mailbox, and floppy applications.  This
disk may not be part of the complete set described below.  It may only
be the part you asked for.  If you have a lot of curiosity the
underpinnings of TCP/IP, get the complete suite from either me, or TAPR.
TAPR would have the most current version information.  The version I am
using is the original one distributed at Dayton in 1989.  I have
modified it to correct some end of line problems in mail files and some
bugs in tracing and added some of the enhanced AX.25 mailbox
capabilities that are kicking around.  Immediately after Dayton, some
fixes were published as Rev. 890421.1 and after that configuration
control went all to hell.  My version has never crashed on an my AT or
XT compatibles, nor on a Unix System V machine.  The code is compilable
with the AT&T compiler.  Joe Buswell, K5JB.)

IF YOU HAVEN'T ALREADY MADE YOUR BACKUP COPIES, DO IT NOW

As distributed (by TAPR), this package contains two diskettes:

    1ea  Plug and Play disk configured for use with an
         IBM PC/clone.

    1ea  Documentation and TNC software disk.

As a first time, or early user you will initially be interested in the
Plug and Play disk. If you are interested in doing development work or
browsing through the source code you will find want to obtain our other
2-disk set that contains all of the sourcecode in 'C'.

This disk is designed to help you get on the air as quickly as possible
running the TCP/IP protocol suite.  What has been done is to put
together a disk that is ready to run, except for a few simple site-
specific things that you'll have to do yourself.

The files you need to modify are the 4 files that contain information
specific to your machine and situation.  Use your favorite text editor
to make the required changes. The files that are provided have been
heavily annotated to *briefly* describe what each function is. See the
documentation referred to below for complete explanations.

The files that need to be changed are:

  \AUTOEXEC.NET  - primary config file for the NET.EXE
                   program. Check each entry line that does
                   NOT begin with an '#'. Substitute your
                   callsign, etc as appropriate.
  \FTPUSERS      - follow the instructions on the sample file,
                   making changes as necessary.
  \BM.RC         - check your hostname, username, and favorite
                   editor.
  \HOST.NET      - prepare a separate hosts.net file which
                   will reflect the hosts accessible from your
                   computer.
and optionally:

  \ALIAS         - File used by BM to make address substitutions.
  \NET\HELPBOX.NET File sent to an AX.25 mbox user who asks for help.
  \FINGER\(users).TXT - See Finger information.

Once you've done this, you should be able to run NET.EXE successfully.

If you have a problem which appears to be hardware related there is a
good deal of information in the documentation provided. Your easiest
solution may, however, be to get in touch with someone who is already
running TCP/IP on your type of equipment.  Problems always seem to get
fixed faster when there's an expert around!

(This is the traditional way to organize net - K5JB)
You will find that this disk is organized into several subdirectories,
and with the files contained therein as follows:

   \(ROOT)__ . . . . . . . . . . . . . . . . autoexec.net
           |                                 ftpusers
           |                                 hosts.net
           |                                 bm.rc
           |                                *net.exe
           |                                *bm.exe
           |                                 alias (optional)
           |
           |___NET___. . . . . . . . . . . . (executables from above)
           |                                 helpbox.net (optional)
           |
           |__FINGER_. . . . . . . . . . . . optional finger files
           |
           |
           |__PUBLIC_. . . . . . . . . . . . downloadable mbox files
           |
           |___SPOOL_. . . . . . . . . . .** net.log (or put in \net)
                     |
                     |
                     |___MAIL. . . . . . .** user.seq
                     |                    ** user.txt
                     |
                     |___MQUEUE. . . . . .** sequence.seq
                     |                    ** #.txt
                     |                    ** #.wrk
                     |
                     |___RQUEUE. . . . . .used if you're a mail
                                          gateway...

(As an aside, if you duplicate this disk for a friend, and you are
*encouraged* to do so, you must use diskcopy and not 'copy *.*' since
there are subdirectories involved)

NOTES

 *   If you are using a hard disk the subdirectory configuration should
     be the same as shown EXCEPT that the files marked with a single
     asterisk '*' need to be placed in a separate subdirectory of your
     root directory.  This directory can be called NET, TCPIP or
     anything of your choice. This subdirectory then becomes the one
     from which you will execute NET.EXE.

 *   The files marked with a double asterisk '**' will be automagically
     installed for you when you execute BM.EXE.

Future revisions:
Revisions to the KA9Q code have been occurring approximately once per
year. When they occur they are announced on the global Internet,
Compuserve, TAPR's Packet Status Register newsletter, Gateway, packet
BBS's and almost anywhere amateur news travels. Revisions, when
announced, are available as follows:

Floppies (IBM format):
Tucson Amateur Packet Radio (TAPR)
Box 12925
Tucson AZ 85732
[phone]

Floppies (other than IBM format):
Future arrangements will be announced when made.

Comments and suggestions concerning this disk package
should be addressed to:

Andy Freeborn N0CCZ
President, TAPR
5222 Borrego Drive
Colorado Springs, CO 80918
N0CCZ @ K0HOA
uucp: winfree!andy
arpa: [e-mail]

*** EOF

Appendices:

The following appendices are:

     1. Net/ROM, incl AX.25 mailbox
     2. Finger, giving the
     3. More mailbox - added features
     4. Floppy use, really?

Search for them with key word, Appendix (n).

Appendix 1: Net/ROM and mailbox

The NET/ROM information was provided by Dan Frank W9NK, author of the
NET/ROM support for NET.EXE.73 -

The NET/ROM support for the KA9Q package serves three purposes:

   1) Existing NET/ROM networks may be used to send IP traffic.
   2) NET may be used as a NET/ROM packet switch.
   3) NET may be used to communicate with NET/ROM nodes, and its
      mailbox facility can accept connects over the NET/ROM network.

"Setting up the NET/ROM Interface"

   No physical interface is completely dedicated to net/rom, which is as
it should be.  You attach all your AX.25 interfaces, of whatever sort.
Then you attach the net/rom pseudo-interface ("attach netrom").  Then
you identify to the net/rom software those interfaces you want to allow
it to use, with the "netrom interface" command.  The format of this
command is:

     netrom interface ax0 #ipnode 192

The first argument is the name of the previously attached interface you
want to use.  The second argument is the alias of your node, to be used in
your routing broadcasts.  The alias is never used for anything else (as
you will see!).  The last number is the net/rom quality figure.  This is
used in computing the route qualities; it represents the contribution of
this interface to the overall computation.  For a 1200 baud half-duplex
connection, 192 is the right number.

   You need a netrom interface command for every interface you're going
to use with net/rom.

"Tracing on the NET/ROM Interface"

   If you want to trace your NET/ROM datagrams, don't try turning
on trace mode for the "netrom" interface.  Nothing will break, but
nothing will happen.  You should trace the individual AX.25 interfaces
instead.

"Routing Broadcasts"

   Once you have set up your interfaces, you need to set some timers.
There are two:  the nodes broadcast interval timer, and the obsolescence
timer.  These are set in seconds, like the smtp timer.  You should usually
set them to an hour.  You can set them to something different, if you want.
If your local net/rom nodes broadcast every hour, but you want to do so
every ten minutes, you can say:

     netrom nodetimer 600
     netrom obsotimer 3600

Every time the obsotimer kicks, the obsolescence counts for all non-permanent
entries are decremented by one.  When the count for an entry falls below
five, it is no longer broadcast.  When it falls to 0, it is removed.  The
count is initialized at 6.  These will eventually be settable parameters;
you can adjust them now by changing the initializers for the variables
in the source file.

   When you first come on the air, you can send out nodes broadcasts to
tell the local nodes that you are available.  Use the command:

     netrom bcnodes ax0

where ax0 is the interface on which you want to send the broadcast.  Do
this for every interface on which you want to do this.

   By default, the NET/ROM code does not broadcast the contents of your
routing table.  This is as it should be, since usually we just want to
be the endpoints of communications rather than relaying NET/ROM traffic.
If you want to be a switch station, include the command:

     netrom verbose yes

in your autoexec.

   Sometimes you can hear broadcasts from nodes that can't hear you.  If
your routing table gets filled with these unusable routes, your node will
grind to a halt.  The solution to this is node broadcast filtering, via
the netrom nodefilter command.  There is a filter list, which contains
a list of callsigns and interfaces.  Then there is a filter mode, which
indicates what to do with the list.

   If the filter mode is "none", no filtering is done.  If it is "accept",
then only broadcasts from the indicated stations on the indicated
interfaces are accepted.  If it is "reject", then all broadcasts
except those from the listed stations on the listed interfaces are
accepted.

   Because the net/rom code cannot at this time recognize unusable
routes and try alternates, I strongly recommend use of the filter
command to restrict broadcast acceptance to those nodes which you
know you can reach.

"The NET/ROM Routing Table"

   The next net/rom commands are those used for maintaining
the routing table.  They fall under the "netrom route" subcommand.
"netrom add" adds a permanent entry to the routing table.  Its format
is:

     netrom route add #foo w9foo ax0 192 w9rly

This command adds an entry for w9foo, whose alias is #foo, route
quality 192, via w9rly on interface ax0.  Let's talk about what this
means.  w9foo is the *destination* node, the one to whom you want
the packets routed by the net/rom network.  w9rly is your *neighbor*,
the net/rom node to which you pass the packet to be forwarded.  Since
w9rly may appear on more than one interface (the callsign may be used
by more than one net/rom node on different bands), we specify that
we are to use ax0 to send the packet.

   With net/rom, like IP, we don't know exactly what route a packet
will take to its destination.  We only know the name of a neighbor
which has indicated a willingness to forward that packet (of course,
the neighbor may be the destination itself, but that's unlikely in
our application).  Net/rom sends the packet to the neighbor, with a
network header specifying our callsign and that of the ultimate
destination (in this case w9foo).

   We can use the netrom route add command to establish a digipeater
path to the neighbor.  For example:

     netrom route add #foo w9foo ax0 192 w9rly wd9igi

This will cause us to use wd9igi as a digipeater in establishing our
connection to the net/rom node w9rly.

   To drop the route to w9foo, you would type

     netrom route drop w9foo w9rly ax0

   To see the contents of your routing table, you may type

     netrom route

and to see the routing entries for an individual station you can type

     netrom route info <callsign>

You may not use an alias as an argument to the netrom route info command.

   I can not stress enough that "route add" and "netrom route add" are two
different commands, with different purposes.  In general, you only need a
"netrom route add" if you need to add a route to a net/rom node via a
digipeater path.  If you find yourself using this command, ask yourself,
"Why am I doing this?"  Many people do not understand that net/rom does
automatic routing (well, sort of :-)).

"The Importance of the Routing Table"

   The NET/ROM routing table is analogous to the IP routing table:  if
there is nothing in it, your NET/ROM traffic will not go out.  You must
either manually enter a list of routes (perhaps via your autoexec.net)
or wait to receive routing broadcasts from your neighbors before your
NET/ROM traffic will leave your station.

   If you go to send packets via NET/ROM and nothing happens, even if
you have trace mode on, make sure that the destination node is in your
NET/ROM routing table.  If sending IP traffic, double check the ARP table
for an appropriate NET/ROM ARP entry for the destination node (see below
for more information on the use of the ARP table).  The ARP table is not
used for NET/ROM transport routing.

"Interfacing with NET/ROMs Using Your Serial Port"

   What if you have a net/rom node or nodes, and you'd like to attach
them to your computer via their serial interfaces, and use net as a
packet switch?  It's very easy:  you have to attach those interfaces,
using the "attach asy" command, but specifying type "nrs" instead of
"slip" or "kiss".  "nrs" is the net/rom serial framing protocol, which
is like KISS, but uses different framing characters and has an 8-bit
checksum.

   When you attach an nrs interface, it can be used for passing IP
datagrams or AX.25 frames over serial lines or modems.  To use it
for net/rom, you have to identify it to the netrom code just like
any other interface, with the "netrom interface" command.

"The Time to Live Initializer"

   The "netrom ttl" command allows setting of the time-to-live
initializer for NET/ROM datagrams.  I recommend a value of 16
for most networks.  Use more if you expect to go more than 16 hops.
The default is 64.

   The purpose of the ttl initializer is to prevent a packet from
getting caught forever in routing loops.  Every router who handles
the packet decrements the ttl field of the network datagram before
sending it on, and when it reaches 0 it is discarded.

"Using NET/ROM Support for IP"

   Now you know all the commands, but how do we actually use net/rom
for IP communications?  This takes two steps:

   Step one:  update the routing table.  In all likelihood, you will
use net/rom to gateway two IP subnets.  So, you'll probably want to
identify a station on each end as a gateway.  Let's say we're on the
Milwaukee subnet, and we want to talk to someone in Madison.  If
we're not the gateway, we just have a routing table entry like this:

     route add [44.92.0.0]/24 ax0 wg9ate-pc.ampr

This specifies that wg9ate should get all packets for the 44.92.0.x
subnet via interface ax0.

   Wg9ate has this routing table entry:

     route add [44.92.0.0]/24 netrom w9mad-pc.ampr

(presuming that w9mad is the Madison gateway).  Now, when the IP layer
at wg9ate gets datagrams for Madison, it knows that they have to go via
net/rom to w9mad.  Notice that we don't specify a "real" interface,
like ax1 or nr0, in the route entry.  The net/rom network layer will
pick the right interface based on its net/rom routing tables.

   We're not done yet, though.  w9mad-pc.ampr is not an ax.25
callsign.  The net/rom send routine called by the IP layer needs
to map from the IP address to an ax.25 address.  It does this via
a manually added arp entry:

     arp add w9mad-pc.ampr netrom w9mad

[We kind of fudged by using the arp table for this purpose, since
there is no way to do automatic address resolution for net/rom,
and arp messages are never sent or received for net/rom nodes.
However, the arp table does contain precisely what we have here:
mappings from IP addresses to callsigns, and it saved a lot of
code to do it this way.]

Notice also that no digipeaters are ever specified in the arp entry
for a net/rom node.  Also, the callsign to which we are mapping
is the final destination of the packet, not the non-destination
neighbor.  That neighbor will be picked based on the net/rom
routing tables.

   So, as a summary, let's look at what happens to a packet that
reaches the IP layer on wg9ate, destined for Madison.  The IP
routing code looks the destination IP address up in the table,
and discovers that it should go via net/rom to w9mad-pc.ampr.
So, it passes the packet to the net/rom send routine.  That
routine uses the arp table to translate w9mad-pc's IP address
to the callsign "w9mad".  Then it passes the packet to the
net/rom routing code.  That code checks to see if the destination
callsign (w9mad) is the same as that of any of its assigned
net/rom interfaces.  Since it isn't, it puts a network layer
header (a.k.a. net/rom level 3 header) on it, and looks for
w9mad in its routing tables.  Presumably, it finds an appropriate
neighbor for the packet, and sends in out via ax.25.  The net/rom
network does the job of actually getting the packet to its
destination.

   At w9mad, the packet's protocol ID causes it to be sent to
the same net/rom routing code that handled the outgoing packet
from wg9ate (running on a different computer, of course).  Now
the destination callsign matches, so the net/rom network layer
header is stripped off, and packet is passed up to the IP layer.
(Net/rom network headers don't have a protocol ID byte, so
we just hope for the best.  If a net/rom node addresses a
net/rom transport layer packet to us, it is likely to be dropped
by IP for any of a number of reasons.)

"The NET/ROM Transport Layer"

   NET/ROM transport is the protocol used by NET/ROM node to
communicate end-to-end.  When a user attaches to a NET/ROM
via AX.25, and asks for a connect to a node in the NODES list,
his local NET/ROM tries to open a transport connection to
the destination node over the NET/ROM network.  NET/ROM transport
packets are carried in NET/ROM network datagrams, just like
IP datagrams.

   You shouldn't use NET/ROM transport when connecting to other
TCP/IP stations.  TCP is a much better protocol than NET/ROM
transport, and makes better use of available bandwidth.  Also,
BM and SMTP are more convenient to use than a TCP/IP station's
mailbox facility.  However, for communicating with AX.25 users
via the NET/ROM network, the transport facilities in NET will
work better (and more easily) than the traditional method of
connecting to your local node via AX.25.

"Connecting via NET/ROM Transport"

   To connect to the node whose alias is FOO and whose callsign is
W9FOO, you can issue either of the following two commands:

     netrom connect foo

     netrom connect w9foo

If foo:w9foo is in your NET/ROM routing table, your station will
transmit a connect request to the appropriate neighbor used to
reach w9foo.

   NET/ROM transport sessions are very much like those for AX.25.
You can use the disconnect, reset, kick, upload, and record
commands, and the session command to switch sessions.

"Displaying the Status of NET/ROM Connections"

   The command

     netrom status

is used to display the status of all NET/ROM connections, which will
include those used in keyboard sessions as well as ones attached to
the mailbox.  For more detailed information on a session, you can
use the address of the NET/ROM control block:

     netrom status <&nrcb>

where <&nrcb> is the hex address given in the short form of the command
or in the "session" display.

"NET/ROM Transport Parameters"

   The NET/ROM transport parameters may be set with the various
NET/ROM subcommands.  Their meanings are listed below:

   acktime: This is the ack delay timer, similarly to ax25 t2.
            The default is 3000 ms.

   choketime: The time to wait before breaking a send choke condition.
              Choke is the term for NET/ROM flow control.

   irtt: The initial round trip time guess, used for timer setting.

   qlimit: The maximum length of the receive queue for chat sessions.
           This is similar to ax25 window.

   retries: Maximum retries on connect, disconnect, and data frames.

   window: Maximum sliding window size, negotiated down at connect
           time.
"The Mailbox"

   The AX.25 mailbox also accepts NET/ROM connections.  The "mbox on"
and "mbox off" commands control whether the mailbox is turned on for
NET/ROM as well as AX.25, and the "mbox" command displays current
mailbox connects of both types.  (See Appendix 3 for more on the mbox.)

   Many people have observed that the AX.25 mailbox requires the user
to enter a carriage return to bring up the banner and prompt.  This is
because of certain defects of that protocol when it is used as the
link layer for several different higher level protocols, and is
unavoidable.  (So stop asking, OK? :-))  The NET/ROM mailbox does
not require the carriage return, and will be activated as soon as
the incoming connection is completed.  (See more on mbox, below - K5JB)

"Where to go for More Information"

   The paper "Transmission of IP Datagrams over NET/ROM Networks"
appeared in the Seventh ARRL Networking Conference papers, available
from the ARRL.  In it, I describe the more technical details of how
the NET/ROM network support works.

   If you want to learn about NET/ROM, talk your local NET/ROM or TheNET
operator out of his or her manual.  If you want to learn more, read
the source code.  That's about it for sources, since the NET/ROM
protocols originated in a commercial product.

"About the Code"

   There has been a great deal of controversy about TheNET, a no-charge
NET/ROM clone for TNCs.  This is not the place to discuss the truth
of the charges leveled by Software 2000 against its authors, but that
situation requires me to make the following statement:

   The NET/ROM transport support in NET.EXE was not taken in any way,
shape or form from NET/ROM (whose source I have never seen) or from
TheNET.  The protocol code is based on protocol 6 from Tanenbaum's
excellent book, Computer Networks, as a moderately careful reading
of both should show.  The source code is freely distributed, so
the curious reader should have the opportunity to check this assertion
if he or she so desires.

   The smoothed round trip time calculation, which is not done in
"real" NET/ROMs (and should be, by the way -- they'd work a whole
lot better) is adapted from that used by KA9Q in the TCP protocol
in NET.  The dicey business of adapting it to a sliding windows
protocol with selective retransmission was done by me, all alone,
after my cries for help on the tcp-group mailing list went unanswered :-).

   I have taken the precaution of copyrighting the NET/ROM code in
NET.  It may be freely distributed for non-commercial purposes, in
whole or in part, and may be used in other software packages such
as BBS systems if so desired, so long as the copyright notice is
not removed from the source files, and the program in which it is
used displays "NET/ROM code copyright 1989 by Dan Frank, W9NK"
when it starts up.

   Any person who wishes to distribute the code, or anything based
on the code, for commercial purposes will find me very reasonable,
but rather insistent about being compensated for the hours I've
spent working on it.  Dan Frank, W9NK

*** EOF

Appendix 2: The Finger Server

In a subdirectory, called, /finger, off of root, put files with name
format, (name).txt, e.g. k5jb.txt, all.txt, etc.  If someone does,
finger @k5jb, (my station), his program responds with something to the
effect:

   Known users at k5jb:
      k5jb
      all

Then, if he sends, finger all@k5jb, my program sends the contents of
all.txt to him.  You can see the results of the finger command by doing,
finger, finger @your_hostname, finger someone@your_hostname, to see what
your files look like to someone else.  I use the all.txt to hold all the
current IP addresses I have assigned in the local area.  Use FTP to get
it from me, if you want.  Joe, K5JB

*** EOF

Appendix 3: Added mailbox (mbox) features.

Notes from K5JB for added mbox features:

What follows is my note from my source code.

This version, 890421.0g (K5JB), allows someone who connects to the mbox,
via AX.25 or Net/ROM, to read mail, kill his mail, see who has mail, get
a help message, get directory lists and download text files.  It searches
the directory, \spool\mail (or $(SPOOL)\mail, if you defined the
environmental variable, SPOOL) for for a *.txt file containing the user's
call sign and if there is one, tells him that he has mail before the
initial prompt.  The prompt, which is compiled in, doesn't show all the
possible commands.  It shows, "Chat", "Send", "Read", "Kill", "Help", and
"Bye".  Additional commands are, "Get", "List" (a directory function) and
"Mail" (list who has mail).  "Read" causes the entire mail file
(call.txt) for that user to be sent.  "Kill" deletes it.  The help file,
helpbox.net can contain information on these unlisted commands, if you
want to enable them.  (The "Users" command is a compile-time selected
option but it doesn't have much useful purpose except to list other users
who might be on the mailbox at the same time you are.)

Mail and other file downloading is primitive and there is no provision
to selectively read mail messages.  If a user has more than one mail
message they are all sent at once.  A Kill command kills all the
messages to him by deleting the .txt file that contains them.
Downloading (receiving) of files (resulting from: read mail, list
directory, get file) can be aborted by the operator sending a character
to the mbox while the downloading is taking place.  (Empty line alone
won't do it.)  A disconnect will stop the downloading, but the IP
operator will get a warning message about clearing garbage.  No harm is
done.

Three file path names were added to support the added functions in
ax_mbx.c.  They are marked below with ">".  In net, version 890421.0,
suffix g, for the MS-DOS computer, only 2 of them are used, *helpbox and
*public.  helpbox.net is a help file that contains whatever you want in
there, and public is a directory off of root that contains files that
are suitable for downloading over ax.25 links.  (In other words, no
binaries, and no monsters).  There is no connect message function
compiled into the suffix i version.  (Suffix g version can use
environmental variables to specify paths different than those compiled
in as defaults.  See the note below.)

For reference, here is the complete list of files declared in files.c
for the MS-DOS computers:

char *startup = "/autoexec.net";   /* Initialization file */
char *userfile = "/ftpusers";      /* Authorized FTP users and passwords */
char *hosts = "/hosts.net";        /* Network host table */
char *mailspool = "/spool/mail";   /* Incoming mail */
char *mailqdir = "/spool/mqueue";  /* Outgoing mail spool */
char *mailqueue = "/spool/mqueue/*.wrk"; /* Outgoing mail work files */
char *routeqdir = "/spool/rqueue"; /* queue for router */
char *alias = "/alias";            /* the alias file */
>char *cmsg = "/net/conmsg.net";  /* connect message for mbox (not used) */
>char *helpbox = "/net/helpbox.net"; /* help file for mbox */
>char *public = "/public";          /* directory downloadable from mbox */
char *fingersuf = ".txt";          /* Text info for finger command */
char *fingerpath = "/finger/";     /* Path to finger info files */

If you use bm.exe as your mailer, you need bm.rc in the root.

(BTW, the "/" in the file names is correct.  The functions that use them
don't care.)

                               HELPBOX.NET

Here is an example of helpbox.net that I use:

(blank line)
This is just a mail drop function.  You can read mail addressed to you or
send mail to someone else in the local area, or someone else on the TCP/IP
network.  Here are the commands that aren't listed in the prompt:

m Lists calls of those who have mail here.

l Lists downloadable file names that are in a public directory.

g (filename) gets one of those files.  Use, g morehelp, to get a more complete
  help file that explains some of the peculiarities of this thing.

Enjoy!  Joe, K5JB
(blank line)
(end of helpbox.net)

Helpbox.net is short because people are prone to type "h" when they
can't think of anything else to do and if the path is poor, a short file
makes the results merciful.  The file, "morehelp" in the \public
directory is much more informative (longer).

*** EOF

Appendix 4: Floppy use

The following suggestion for floppy users provided by John Conner,
WD0FHG.
------
Note to floppy users with two drives and using DOS 3.0 or later (you
don't have two drives?---go trade a HT battery pack for one they are
much more useful :-):

At present NET does not understand different drives.  To make B:
accessable to NET enter the following command from A:> BEFORE running
NET.

    JOIN B: A:\PUBLIC

This command makes drive B: appear to be the subdirectory PUBLIC on
drive A: and all files and subdirectories on B: can be accessed by
adding \PUBLIC\ to the file name.  In effect we just doubled the size of
the A: drive.  A couple of cautions about using this command.  First be
sure you have a formated disk in B: when running NET or it will hang
trying to read the B: disk. Second the JOIN command is actually a file
on your DOS disk and will need to be on the disk in the A: drive when
you enter the command.

(PUBLIC can be any name that is not already used on drive A:. I use the
\PUBLIC as the area all ftp users have access to.  WD0FHG)

*** EOF